A Reed-Solomon Product Code (RSPC) block 80 use rows and columns to encode an array of data bytes. In a DVD application, 172×192 bytes of data are encoded by adding sixteen bytes 82 (i.e., PO) in each column and ten bytes 84 (i.e., PI) in each row to form the final RSPC code 80 of 182×208 bytes, as shown in FIG. 1. To better decode an RSPC block 80, iterative methods are conventionally used to decode by row and column and then by row and column again until either no more errors exist in the code or a best resulting code is established.
Each iteration is capable of changing up to all of the data bytes in the RSPC block 80 and update the decoding results in response to the changes. The ability to change the data commonly means that either the data block is saved locally or a lot of bandwidth is used moving the data back and forth from an external memory over a memory bus. Conventional decoding methods access each of the data bytes multiple times during processing. For example, after finishing decoding of a particular row, some of the data bytes in the particular row are often updated to correct errors found by the decoding. Therefore, when column decoding begins, column corrections are calculated based on partially corrected data. A next iteration of row decoding uses the partially corrected data from the previous column decoding, and so on.
As each decoding step processes a row or column, either the data bytes are saved locally until the iterations are complete or the data bytes are accessed across the memory bus in time for the associated row or column decode. Storing all of the data bytes locally results in a large local memory (i.e., 182 columns×208 rows×2 copies=75,712 bytes). Storing all of the data bytes in an external memory consumes a large amount of a memory bus bandwidth.